Summary

Adds support for synchronously returning workflow execution results from the HTTP trigger endpoint. By default, the workflow HTTP endpoint fires-and-forgets (202 Accepted). With this change, callers can set the x-ms-wait-for-response: true header to wait for the workflow to complete and receive the result directly in the HTTP response (200 OK). Results are returned as plain text by default, or as a structured JSON object when Accept: application/json is specified.

Changes

New feature

• Parse the x-ms-wait-for-response header in RunWorkflowOrchestrationHttpTriggerAsync
• New WaitForWorkflowCompletionAsync method that calls WaitForInstanceCompletionAsync and handles failure/completed/unexpected statuses
• Support Accept: application/json header to return a structured JSON response (runId, status, result)
• POCO results from executors are properly serialized as nested JSON objects (using JsonElement) rather than double-encoded strings

Code quality improvements

• Extracted WaitForResponseHeaderName constant (replaces two inline string literals)
• Extracted ShouldWaitForResponse(req, defaultValue) helper to eliminate duplicated header-parsing logic across workflow and agent triggers
• Extracted AcceptsJson(req) helper to deduplicate Accept header checks across 4 response methods
• Added optional acceptsJson parameter to CreateErrorResponseAsync to avoid redundant header reads within WaitForWorkflowCompletionAsync

Docs & samples

• Updated 01_SequentialWorkflow/README.md with curl/PowerShell examples for the new header
• Added demo.http entries for wait-for-response scenarios (plain text and JSON)

Tests

• Added integration test in WorkflowSamplesValidation.cs verifying the header works end-to-end

JSON response examples

Plain text (default):

Cancellation email sent for order 12345 to jerry@example.com.

JSON (with Accept: application/json):

{
  "runId": "abc123def456",
  "status": "Completed",
  "result": "Cancellation email sent for order 12345 to jerry@example.com."
}

JSON with POCO result (executor returns an object):

{
  "runId": "abc123def456",
  "status": "Completed",
  "result": { "orderId": 123, "email": "jerry@example.com" }
}

Description

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the Contribution Guidelines
• All unit tests pass, and I have added new tests where possible
• Is this a breaking change? If yes, add "[BREAKING]" prefix to the title of the PR.